Systems and methods for storing, retrieving, and manipulating data in medical processing devices

ABSTRACT

A device has processing hardware to carry out a—blood processing procedure. A processing control manager resides on the device to monitor status conditions over time during the blood processing procedure. A data interface also resides on the device. The data interface includes a flash memory data storage medium formatted to allocate discrete block file spaces to receive data. Chronologic data or time-specific data are created based upon sensed conditions by a data generator task, which also resides on the device. A file manager task appends chronologic data to an allocated file space to create a chronologic block file, which, when read, provides a time-ordered account of processing activities or hardware conditions. The file manager also operates to block-write time-specific data to another allocated file space, which, when read, creates a snap-shot of processing conditions at a given point in time. The data file structure created on the flash memory medium withstands corruption of data due to power failure.

FIELD OF THE INVENTION

[0001] The invention relates to systems and methods for recording dataduring the course of fluid processing procedures, such as those carriedout by blood processing systems and the like.

BACKGROUND OF THE INVENTION

[0002] Today people routinely separate whole blood by centrifugationinto its various therapeutic components, such as red blood cells,platelets, and plasma.

[0003] These and other medical processing devices are often controlledusing microprocessors with resident program software. Themicroprocessors also usually include some type of interface throughwhich the operator views and comprehends information regarding theoperation of the fluid processing systems.

[0004] These and other medical processing devices also often require theability to record key control and processing parameters during thecourse of a procedure, as well as to keep track of operator interventionduring the procedure. These data recording functions are useful, as theysupport, e.g., GMP requirements, instrument trouble shooting and problemdiagnosis, and instrument performance evaluation. Still, whileimportant, data recording functions should not compete or interfere withthe overall processing tasks and objectives of the procedure.

[0005] As the operational and performance demands upon such fluidprocessing systems become more complex and sophisticated, the needexists for integrating, automating, and fortifying data recordingfunctions.

SUMMARY OF THE INVENTION

[0006] The invention provides systems and methods, which fully integratedata recording functions with processing functions. Thus, the sameinstrument that carries out the processing tasks also performs the datarecording functions, without the need for add-on, external datarecording systems.

[0007] The invention also provides systems and methods, which fullyautomate necessary data recording functions, so that they can beaccomplished “in the background,” without significant operatorintervention or control.

[0008] The invention also provides robust systems and methods, whichcarry out data recording functions that withstand real world abuse, suchas power failure or corruption of stored data. This “crash-proof” aspectis particularly significant in an embedded software systems environment,where an instrument may be powered off at any time.

[0009] One aspect of the invention provides systems and methods forprocessing data during a blood processing procedure. The systems andmethods monitor status conditions over time during the blood processingprocedure and generate data based upon monitored status conditions. Thesystems and methods write the data to a flash memory storage medium. Ina preferred embodiment, the systems and methods retrieve and manipulatethe data written to the flash memory storage medium.

[0010] The use of flash memory provides reliability and compact size, sothat robust data storage, retrieval, and processing functions can becarried out on-board a blood processing device, without need forexternal computing devices and without concern about the durability andreliability of the data storage functions.

[0011] According to another aspect of the invention, blood processingsystems and methods employ a device that has processing hardware tocarry out a blood processing procedure. A processing control managerresides on the device to monitor status conditions over time during theblood processing procedure. A data interface also resides on the device.The data interface includes a data storage medium formatted to allocatediscrete block file spaces to receive data.

[0012] In a preferred embodiment, chronologic data or time-specific datacan be created, based upon sensed conditions by a file generator task,which resides on the device. A file manager task operates to appendchronologic data in an allocated file space to create a chronologicblock file. When read, the chronologic block file provides atime-ordered account of processing activities or hardware conditions.The file management element also operates to block-write time-specificdata to another allocated file space. When read, each time-specific datafile provides a snap-shot of processing conditions at a given point intime. The data file structure created withstands corruption of data dueto power failure.

[0013] The features and advantages of the invention will become apparentfrom the following description, the drawings, and the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014]FIG. 1 is a diagrammatic view of a dual needle platelet collectionsystem that includes a controller that embodies the features of theinvention;

[0015]FIG. 2 is a diagrammatic flow chart view of the controller and theassociated instrument manager and graphical user interface;

[0016]FIG. 3 is another diagrammatic view of the controller and theassociated instrument manager and graphical user interface shown in FIG.2, and further showing the command and status flow hierarchy;

[0017]FIG. 4 is a view of the dual region graphical user interfacescreen, showing the block and touch activated fields that the interfacescreen contains, and also showing the Main Menu in the working region ofthe interface screen;

[0018]FIG. 5 a view of the dual region interface screen, showing theSelect Procedures Submenu in the working region of the interface screen;

[0019]FIG. 6A a view of the dual region interface screen, showing theSpecial Features Submenu in the working region of the interface screen;

[0020]FIG. 6B a view of the dual region interface screen, showing theFile Manger Submenu in the working region of the interface screen;

[0021]FIG. 7 is a diagrammatic flow chart view of the controller and theassociated data interface;

[0022]FIG. 8 is a diagrammatic view of the block file structure of thestorage device of the data interface shown in FIG. 7;

[0023]FIG. 9 is a diagrammatic view of the directory table of the blockfile structure shown in FIG. 8;

[0024]FIG. 10 is a diagrammatic view of one block file space allocatedin the block file structure shown in FIG. 8;

[0025]FIG. 11 is a diagrammatic view of the ringfile function, whichcontrols the writing of data into the block file space shown in FIG. 10;

[0026]FIG. 12 a view of the dual region interface screen, showing theFile System Information Submenu in the working region of the interfacescreen;

[0027]FIG. 13 a view of the dual region interface screen, showing theFile Directory Submenu in the working region of the interface screen;

[0028]FIG. 14 is a representative Procedure Report that the datainterface shown in FIG. 7 can generate;

[0029]FIG. 15 is a representative Event Report that the data interfaceshown in FIG. 7 can generate;

[0030]FIG. 16 a view of the dual region interface screen, showing thePrint Procedure Reports Submenu in the working region of the interfacescreen;

[0031]FIG. 17 a view of the dual region interface screen, showing theLog Viewer Submenu in the working region of the interface screen;

[0032]FIG. 18 a view of the dual region interface screen, showing theSystem Configuration Submenu in the working region of the interfacescreen;

[0033]FIG. 19 a view of the dual region interface screen, showing theSet Configuration Submenu in the working region of the interface screen;

[0034]FIG. 20 is a schematic view of the predictor function of the datainterface; and

[0035]FIG. 21 is a schematic view of the import configuration functionof the data interface.

[0036] The invention may be embodied in several forms without departingfrom its spirit or essential characteristics. The scope of the inventionis defined in the appended claims, rather than in the specificdescription preceding them. All embodiments that fall within the meaningand range of equivalency of the claims are therefore intended to beembraced by the claims.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0037]FIG. 1 shows in diagrammatic form a fluid processing system 10.The system 10 can be used for processing various fluids. The system 10is particularly well suited for processing fluids for medical purposes,like whole blood and other suspensions of biological cellular materials.Accordingly, the illustrated embodiment shows the system 10 used forthis purpose.

[0038] I. The Separation System

[0039] The system 10 includes an arrangement of durable hardwareelements. The hardware elements will vary according to the nature andtype of processing system. In the context of processing whole blood, thehardware elements will include a centrifuge 12, in which whole blood(WB) is separated into its various therapeutic components, likeplatelets, plasma, and red blood cells (RBC). The hardware elements willalso include various pumps, which are typically peristaltic (designatedP1 to P4); and various in line clamps and valves (designated V1 to V3).Of course, other types of hardware elements will typically be present,which FIG. 1 does not show, like solenoids, pressure monitors, and thelike.

[0040] The system 10 typically also includes some form of a disposablefluid processing assembly 14 used in association with the hardwareelements.

[0041] In the illustrated blood processing system 10, the assembly 14includes a two stage processing chamber 16. In use, the centrifuge 12rotates the processing chamber 16 to centrifugally separate bloodcomponents.

[0042] The construction of the two stage processing chamber 16 can vary.For example, it can take the form of double bags, like the processingchambers shown in Cullis et al. U.S. Pat. No. 4,146,172. Alternatively,the processing chamber 16 can take the form of an elongated two stageintegral bag, like that shown in Brown U.S. Pat. No. 5,370,802.

[0043] In the illustrated blood processing system 10, the processingassembly 14 also includes an array of flexible tubing that forms a fluidcircuit. The fluid circuit conveys liquids to and from the processingchamber 16. The pumps P1-P4 and the valves V1-V3 engage the tubing togovern the fluid flow in prescribed ways. The fluid circuit furtherincludes a number of containers (designated C1 to C3) to dispense andreceive liquids during processing. A controller 18 governs the operationof the various hardware elements to carry out one or more processingtasks using the assembly 14. The invention specifically concernsimportant attributes of the controller 18.

[0044] The system 10 can be configured to accomplish diverse types ofblood separation processes. FIG. 1 shows the system 10 configured tocarry out an automated two needle platelet collection procedure.

[0045] In a collection mode, a first tubing branch 20 and the wholeblood inlet pump P2 direct WB from a draw needle 22 into the first stage24 of the processing chamber 16. Meanwhile, an auxiliary tubing branch26 meters anticoagulant from the container C1 to the WB flow through theanticoagulant pump P1.

[0046] The container C2 holds saline solution. Another auxiliary tubingbranch 28 conveys the saline into the first tubing branch 20, via the inline valve V1, for use in priming and purging air from the system 10before processing begins. Saline solution is also introduced again afterprocessing ends to flush residual components from the assembly 14 forreturn to the donor.

[0047] Anticoagulated WB enters and fills the first stage 24 of theprocessing chamber 24. There, centrifugal forces generated duringrotation of the centrifuge 12 separate WB into red blood cells (RBC) andplatelet-rich plasma (PRP).

[0048] The PRP pump P4 operates to draw PRP from the first stage 24 ofthe processing chamber 16 into a second tubing branch 30 for transportto the second stage 32 of the processing chamber 16. There, the PRP isseparated into platelet concentrate (PC) and platelet-poor plasma (PPP).

[0049] The system 10 includes a recirculation tubing branch 34 and anassociated recirculation pump P3. The processing controller 18 operatesthe pump P3 to divert a portion of the PRP exiting the first stage 24 ofthe processing chamber 16 for remixing with the WB entering the firststage 24 of the processing chamber 16.

[0050] As WB is drawn into the first chamber stage 24 for separation,the illustrated two needle system simultaneously returns RBC from thefirst chamber stage 24, along with a portion of the PPP from the secondchamber stage 32, to the donor through a return needle 36 through tubingbranches 38 and 40 and in line valve V2.

[0051] The system 10 also collects PC in some of the containers C3through tubing branches 38 and 42 and in line valve V3 for storage andtherapeutic use. The system 10 can also collect PPP in some of thecontainers C3 through the same fluid path.

[0052] II. The System Controller

[0053] The controller 18 carries out the overall process control andmonitoring functions for the system 10 as just described.

[0054] In the illustrated and preferred embodiment (see FIG. 2), thecontroller comprises a main processing unit (MPU) 44. In the preferredembodiment, the MPU 44 comprises a type 68030 microprocessor made byMotorola Corporation, although other types of conventionalmicroprocessors can be used.

[0055] In the preferred embodiment, the MPU 44 employs conventional realtime multi-tasking to allocate MPU cycles to processing tasks. Aperiodic timer interrupt (for example, every 5 milliseconds) preemptsthe executing task and schedules another that is in a ready state forexecution. If a reschedule is requested, the highest priority task inthe ready state is scheduled. Otherwise, the next task on the list inthe ready state is schedule.

[0056] A. Functional Hardware Control

[0057] The MPU 44 includes an application control manager 46. Theapplication control manager 46 administers the activation of a library48 of control applications (designated A1 to A3). Each controlapplication A1-A3 prescribes procedures for carrying out givenfunctional tasks using the system hardware (e.g., the centrifuge 12, thepumps P1-P4, and the valves V1-V3) in a predetermined way. In theillustrated and preferred embodiment, the applications A1-A3 reside asprocess software in EPROM's in the MPU 44.

[0058] The number of applications A1-A3 can vary. In the illustrated andpreferred embodiment, the library 48 includes at least one clinicalprocedure application A1. The procedure application A1 contains thesteps to carry out one prescribed clinical processing procedure. For thesake of example in the illustrated embodiment, the library 48 includes aprocedure application A1 for carrying out the dual needle plateletcollection process, as already generally described in connection withFIG. 1. Of course, additional procedure applications can be, andtypically will be, included. For example, the library 48 can include aprocedure application for carrying out a conventional single needleplatelet collection process (A1′).

[0059] In the illustrated and preferred embodiment, the library 48 alsoincludes at least one additional, non-procedure application. Thenon-clinical procedural application contains the procedures to carry outa system configuration or support utility. For the sake of example inthe illustrated embodiment, the library 48 includes a configurationapplication A2, which contains the procedures for allowing the operatorto configure the default operating parameters of the system 10. Thelibrary 48 also includes a main menu application A3, which coordinatesthe selection of the various applications A1-A3 by the operator, as willalso be described in greater detail later.

[0060] Of course, additional non-clinical procedure applications can be,and typically will be, included. For example, the library 48 can includea diagnosis application, which contains the procedures aiding servicepersonnel in diagnosing and troubleshooting the functional integrity ofthe system, and a system restart application, which performs a fullrestart of the system, should the system become unable to manage orrecover from an error condition.

[0061] An instrument manager 50 also resides as process software inEPROM's in the MPU 44. The instrument manager 50 communicates with theapplication control manager 46. The instrument manager 50 alsocommunicates with low level peripheral controllers 52 for the pumps,solenoids, valves, and other functional hardware of the system.

[0062] As FIG. 3 shows, the application control manager 46 sendsspecified Perform_Function# commands in abstract form to the instrumentmanager 50, as called up by the activated application A1-A3. In responseto these abstract commands, the instrument manager 50 identifies theperipheral controller or controllers 52 for performing the function andcompiles hardware-specific Operate_Hardware# commands into the commandtables for the particular peripheral controllers 52. The peripheralcontrollers 52 communicate directly with the hardware to implement thehardware-specific commands generated by the instrument manager 50,causing the hardware to operate in a specified way to carry out theabstract Perform_Function# commands. A communication manager 54 manageslow-level protocol and communications between the instrument manager 50and the peripheral controllers 52.

[0063] As FIG. 3 also shows, the instrument manager 50 also conveys backto the application control manager 46 status data about the operationaland functional conditions of the processing procedure. The status datais expressed in terms of, for example, fluid flow rates, sensedpressures, and fluid volumes measured.

[0064] The application control manager 46 processes and uses the statusdata in various ways. In one way, the application control manager 46transmits selected status data for display to the operator, as will bedescribed later. In another way, the application control manager 46monitors operational and functional conditions using the status data todetect abnormal system conditions requiring operator intervention orsystem shutdown.

[0065] In the preferred embodiment (see FIG. 2), the MPU 44 alsoincludes a condition manager 56 that resides in the data flow pathbetween the instrument manager 50 and the communications manager 54. Thecondition manager 56 also monitors status data and other operationalstates of the hardware to detect abnormal conditions that are either notdetected or are left uncorrected by the application control manager 46.Upon detecting such abnormal conditions, the condition manager 56provides fail-safe support by suspending system operation.

[0066] The described control hierarchy creates an abstract, “virtual”interface between the applications resident in the application controlmanager 46 and the hardware elements of the system 10. The high levelprocess software resident in the application control manager 46communicates with lower level implementing process software in theinstrument manager 50, instead of communicating directly with hardwareelements. In this way, the intermediate instrument manager 50 isolatesor “hides” all hardware-specific commands from the application controlmanager 46. The applications pass abstract Perform_Function# commands tothe instrument manager 50, and the instrument manager 50 converts theseabstract commands into the specific Operate_Hardware# commands unique tothe particular hardware elements, all without further participation bythe procedure applications A1-A3 themselves. The data flow between theinstrument manager 50 and the hardware elements of the system 10 isinvisible to the activated application A1-A3.

[0067] The creation of the virtual interface between high level processsoftware and the hardware elements provides considerable flexibility inadding or modifying the process software of the high level applicationsA1-A3 for controlling hardware functions. New or modified processsoftware for the applications need only to include specifiedhardware-non-specific abstract Perform_Function# commands to gainimmediate linkage to the virtual hardware interface. Likewise, additionor modification of specific hardware requires only changes to the lowlevel process software of the instrument manager 50. Because of thevirtual interface, hardware changes require minimal changes to the highlevel software in the application control manager 46.

[0068] As described above, the instrument manager 50 forms a part of thesame MPU in which the application control manager 46 resides.Alternatively, because of the virtual nature of the interface, theinstrument manager 50 can reside on a separate processing unit.

[0069] B. User Interface Control

[0070] In the illustrated embodiment, the MPU 44 also includes aninteractive user interface 58. The interface 58 allows the operator toview and comprehend information regarding the operation of the system10. The interface 58 also allows the operator to select applicationsresiding in the application control manager 46, as well as to changecertain functions and performance criteria of the system 10.

[0071] The interface 58 includes an interface screen 60 and, preferably,an audio device 62. The interface screen 60 displays information forviewing by the operator in alphanumeric format and as graphical images.The audio device 62 provides audible prompts either to gain theoperator's attention or to acknowledge operator actions.

[0072] In the illustrated and preferred embodiment, the interface screen60 also serves as an input device. It receives input from the operatorby conventional touch activation, as will be described later.Alternatively or in combination with touch activation, a mouse orkeyboard could be used as input devices.

[0073] An interface controller 64 communicates with the interface screen60 and audio device 62. The interface controller 64, in turn,communicates with an interface manager 66, which in turn communicateswith the application control manager 46. The interface controller 64 andthe interface manager 66 reside as process software in EPROM's in theMPU 44.

[0074] In use, the application control manager 46 sends to the interfacemanager 66 specified field values reflecting selected status datareceived from the instrument manager 50. The application control manager46 also sends to the interface manager 66 prescribed abstractCreate_Display# and Create_Audio# commands called for by the activatedapplication.

[0075] The interface manager 66 processes these field values and theabstract Create_Display# commands to generate specific Format_Display#commands. The Format_Display# commands control the particular format,attributes, and protocols necessary to create, refresh, and close thevisual display on the interface screen 60.

[0076] Likewise, the interface manager 66 processes the abstractCreate_Audio# commands to generate specific Format_Audio# commands. TheFormat_Audio# commands dictate the format and attributes of the audiooutput called for by the activated application.

[0077] The interface manager 66 conveys the processed Format_Display#and _Audio# commands to the interface controller 64. The interfacecontroller 64 provides low level control functions that draw boxes andlines, forms text or graphical characters, and provides the formattingant attributes of the display on the interface screen 60. The interfacecontroller 64 also provides low level control functions that drive theaudio device 62 based upon Format_Audio# commands received from theinterface manager 66.

[0078] The interface controller 64 also accepts Field#_Select commandsgenerated by touch activation of the interface screen 60, as will bedescribed in greater detail later. The interface controller 64 passesthis touch activated input to the interface manager 66 in the form ofTouch#_Codes. The interface manager 66 processes the Touch#_Codes to theapplication control manager 46, either as function codes or as changedfield values. The application control manager 46 implements the functioncodes or changed field values and passes them to the instrument manager50.

[0079] This control hierarchy also creates an abstract, “virtual”interface between the functional processors of the controller 18 and theinterface 58. The high process software of the interface manager 66isolates and “hides” all formatting and protocol issues used in creatingthe interface 58 from the applications used to control hardwarefunctions of the system 10. The process software of the applicationsA1-A3, through the application control manager 46, pass abstract fieldvalues and Create_Display# and Create_Audio# commands to the interfacemanager 66. The process software of the interface manager 66 convertsthese abstract commands into the specific commands that control thetextual and graphic formats and audio formats of the operator interface58, without further participation by the procedure applications A1-A3themselves. The data flow between the interface manager 66 and theinterface controller 64 is invisible to the data flow between theapplication control manager 46 and the instrument manager 50.

[0080] This control hierarchy lends further flexibility in adding ormodifying applications for controlling hardware functions. New ormodified applications need only to include textual field value outputsand the prescribed Create_Display# or Create_Audio# commands to gainimmediate linkage to the operator interface.

[0081] (I) Interface Screen Format

[0082] In the illustrated and preferred embodiment (see FIG. 4), theFormat_Display# commands of the interface manager 66 formats informationfor display on the interface screen 60 in two distinct viewing regions,called the status region 68 and the working region 70. Preferably, thetwo viewing regions 68 and 70 are fixed in relative position andunchanging in size on the interface screen 60. This provides continuityand consistency to the appearance of the interface 58, even as thefunctional hardware of the system cycle through different processingmodes. The uniformity and consistency of the dual viewing regions 68 and70 of the interface 58 reduce operator confusion and the likelihood oferror.

[0083] The status region 68 and the working region 70 are each dedicatedto different types and levels of information. Nevertheless, the tworegions 68 and 70 are always displayed simultaneously to provide theoperator views of both high level “big picture” information and lowlevel “detailed” information.

[0084] The working region 70 provides the means for the operator toselect and activate any one of the system-resident applications A1-A3.The working region 70 displays all specific procedure-dependentinformation then called for by the Create_Display# commands generated bythe activated application A1-A3. The considerable detail of informationdisplayed in the working region 70 allows the operator to monitor andchange the ongoing process in real time.

[0085] On the other hand, the status region 68 continuously showsprescribed procedure-dependent information of a more general and“overview” nature, about which a operator routinely needs continuousknowledge and immediate access. The status region 68 continuouslydisplays this general information to keep the operator appraised of theoverall status of the ongoing process, even when the operator is usingthe working region 70 to monitor and change more detailed aspects of theprocesses. In the illustrated and preferred embodiment, the statusregion 68 also provides means for the operator to respond to alarms ormalfunctions.

[0086] The two viewing regions 68 and 70 allow the operator to use theinterface 58 quickly to find and select among detailed procedures,functions, and options during system operation, or to perform off-linefunctions, without losing touch with the overall status of the ongoingprocedure. The two viewing regions 68 and 70 permit the operator tonavigate what is in reality a multiple-level menu structure to attend todetails on one menu level, without necessarily moving in steps up anddown the menu structure and without losing the ability to, on command,immediately jump between higher and lower menu levels.

[0087] In the illustrated embodiment, the viewing regions 68 and 70 arevertically separated by a graphical line or line of characters 72, withthe status region 68 occupying the upper one-third of the screen 60 andthe working region 70 occupying the lower two-thirds of the screen 60.It should be appreciated, however, that the viewing regions 68 and 70could be separated horizontally in a side by side relationship, andoccupy differing proportions of the screen The status region 68 and theworking region 70 display information in fields. The Format_Display# forthe particular display that the interface manager 66 generates iscomposed of a list of such fields specifying, for each field, itslocation, size, and type in the region and the format of information itcontains.

[0088] As will be discussed in greater detail later, the fields canformatted as individual touch selectable buttons. The fields can also beformatted as an array of touch selectable button fields, which present afield of choices to the operator.

[0089] The fields can also be formatted as blocks comprising alpha ornumeric data strings, or textual data comprising multiple lines ofline-wrapped, scrollable text, or graphic images. The fields can also beformatted to be bar graph fields, which display numeric format ingraphical form.

[0090] The interface manager 66 includes constant (ROM-based) structuresin look-up table form that store data describing the layout andformatting of all display attributes, including regions, field type, andfield location within the regions. The interface manager 66 storesdynamic (RAM-based) structures that describe the present state of theinterface display. Upon receiving a given Create_Display# command fromthe activated application, the interface manager 66 examines theROM-based table structures and the RAM-based status structures to createor update the RAM-based status structures, as called for by theactivated application. The interface manager 66 includes atime-triggered task routine that performs all operations required toperiodically update screen 60 and audio outputs. The interface manager66 sends this processed information to the interface controller 64 forimplementation.

[0091] The interface manager 66 also holds a Function#_Code associatedwith each touch selectable button field identified by the Touch#_Codereceived from the interface controller 64. The Function#_Codes arearranged in constant (ROM-based) look-up table form according to regionand field location within the region, as identified by the Touch#_Code.The interface controller 64 registers the region and field location whena given button is touched, passing this information in the form of aTouch#_Code to the interface manager 66. The interface manager 66includes a process button utility that awaits and asynchronouslyprocesses this information by examining the ROM-based table structureand sending the appropriate Function#_Code to the application controlmanager 46 for implementation.

[0092] The information and format selected for display in the statusregion 68 and the working region 70 can vary.

[0093] a. The Status Region

[0094] In the illustrated embodiment (see FIG. 4), the status region 68includes a MAJOR MODE field 74, which contains the description of theclinical procedure activated; a MINOR MODE field 76, which contains aone or two word description of the procedure status; and a WB PROCESSEDfield 78, which contains the amount of blood drawn from the donorthrough the draw pump P2 during processing, expressed numerically inunits of ml.

[0095] In the illustrated embodiment (FIG. 4), the status region 68 alsoincludes an array of touch selectable button fields, labeled, e.g., HELP80, MAIN MENU 82, PROCEDURE DISPLAY 84, and PAUSE/END 86. When touched,each cause the interface manager 66 to transmit a prescribed functioncode for implementation by the application control manager 46, withoutaltering the display of information in the blocks fields 74/76/78 on thestatus region 68.

[0096] The status region 68 also includes context-dependent NOTE/WARNINGPROMPT button field 88 that occupies a fixed location on the right side,top position, of the status region 68 when an alarm or warning isactive. The NOTE/WARNING PROMPT button field 88 is not displayed when analarm or warning is not active. A MUTE button field 90 also occupies afixed location on the left side, top position, of the status region 68when an alarm is active. A WARNING/ALARM block field also occupies afixed location on the center, bottom position, of the status region whenan alarm is active.

[0097] b. The Working Region

[0098] In the illustrated and preferred embodiment, the working region70 shows by default the Main Menu display called for by the main menuapplication A3. The Main Menu display includes an array of touchselectable button fields 94 and 96.

[0099] When touched, the CHOOSE PROCEDURE button field 94 calls up afunction that displays a Procedure Submenu in the working region 70 (seeFIG. 5). The Procedure Submenu lists in an array of touch selectablebutton fields 104 and 106 all clinical procedure applicationsadministered by the application control manager 46, which in theillustrated implementation is the Dual Needle Procedure Application A1and the Single Needle Procedure Application A1′. When touched, aprocedure application button field calls up a function that directs theapplication control manager 46 to activate the associated application.The activated application generates its own designated Create_Display#commands, which the interface manager 66 implements to change thedisplay in the working region 70.

[0100] When touched, the SPECIAL FEATURES button field 96 calls up afunction that displays a Special Features Submenu in the working region70 (see FIG. 6). The Features Submenu lists in an array of touchselectable button fields 200 designated non-clinical procedure specificapplications administered by the application control manager 46. When agiven special procedures application button is touched, that applicationis activated and the display in the working region 70 changes inresponse to the Create_Display# commands of the activated application.Further details of certain buttons in the fields 200 will be providedlater.

[0101] Further details of the controller 18 and the graphical userinterface manager 66 as described can be found in U.S. Pat. No.5,581,687, which is incorporated herein by reference.

[0102] C. The Data Interface

[0103] In the illustrated and preferred embodiment (see FIG. 7), thecontroller 18 also includes a data interface 202. The data interface 202forms self-contained, integrated part of the software and hardwarearchitecture of the controller 18. The data interface 202 automates thecollection, retention, and manipulation of key control and processingparameters and operator steps during a given processing application. Thedata interface 202 retains the information in a data structure in a massdata storage device 204, which also forms an integral part of thecontroller 18. The data structure of the storage device 204 permitsinformation to be stored, retrieved, and manipulated in a securefashion, which is resistant to corruption due to unexpected loss ofpower. The data structure of the storage device 204 also permits storedinformation to be retrieved and formatted into printed reports.

[0104] While not essential to its operation, the data interface 202 canalso, if desired, be linked to one or more external computers 206 and206′. The data interface 202 can download stored information to thecomputers 206 206′ in either a structured or an arbitrary order, as willbe described in greater detail later.

[0105] The data interface 202 can be implemented in various ways. In thepreferred embodiment, the mass storage device 204 comprises a flashmemory card, e.g., one conforming to the PCMCIA Type II, PC Card ATAstandard hardware interface. Conventionally, the flash memory storagedevice 204 can support storage ranges from 2 to 85 megabytes. In atypical implementation, the flash memory storage device 204 can holdabout 8 megabytes of data.

[0106] The flash memory storage device 204 lends itself to use with theintegrated data interface 202, compared to conventional hard drivestorage mediums. The flash memory device 204 provides ease of formattingand fast data access time. The flash memory device 204 presents a smallcompact size, which does not compete for space with blood processinghardware. The flash memory device 204 has no mechanical components, andis therefore extremely reliable and is not prone to failure caused byrepeated use. The flash memory device 204 also is durable, beingresistant to vibration and other forces that a centrifugal bloodprocessing device routinely generates during a blood processingprocedure. The flash memory device 204 also is easy to service andreplace on site.

[0107] The data interface 202 also includes additional hardwareinput/output devices 208, 210, 212, and 348, which can take the form of,e.g., conventional serial RS-232C port links. Other input/outputdevices, such as conventional parallel port links and one or more orEthernet™ communication links, can be used.

[0108] In the illustrated embodiment (see FIG. 7), one port link 208communicates with an external a bar code scanner 214. A second port 210communicates with one external computer 206, previously described. Athird port link 212 communicates with an external printer 216. A fourthport link 348 communicates with the other external computer 206′.

[0109] The data interface 202 also includes various process softwaremodules 218 to 230 residing in EPROM's in the MPU 44. The processsoftware modules 218 to 230 carry out prescribed data processing tasks.

[0110] The number and type of software modules 218 to 230 can vary. Inthe illustrated embodiment, one module 218 implements a COMMUNICATIONSMANAGER task. The COMMUNICATIONS MANAGER task module 218 handles lowerlevel data transfers to and from the RS-232C port links 208, 210, 212,and 348. The COMMUNICATIONS MANAGER task module 218 prevents the MPU 44from transferring data faster than it can be transmitted by therespective RS-232C port links 208, 210, 212, and 348.

[0111] Another module 220 implements a BAR CODE task. The BAR CODE taskmodule 220 receives raw ASCII data input from the bar code scanner 214,received through the bar code scanner port link 208. The BAR CODE taskmodule 220 parses the scanned data and assembles it into an inputcompatible with another module, called the PROCEDURE DRIVER TASK module222, which will be described in greater detail later. The PROCEDUREDRIVER TASK module 222 also confirms that the scanned data hasregistered the scanned input, and, once confirmed, the BAR CODE taskmodule 220 formats a feedback message output 232, as will be describedlater.

[0112] The data interface 202 also includes other core processingmodules, which implement, respectively, a PROCEDURE DRIVER task, a FILESYSTEM task, a REPORT task, a DATA EXCHANGE task, a DATA DUMP task, anda USER INTERFACE task. The details of these tasks will now be described.

[0113] (I) The PROCEDURE DRIVER Task

[0114] The PROCEDURE DRIVER task module 222 receives information fromthe application control manager 46 and the BAR CODE task module 220. ThePROCEDURE DRIVER task module 222 registers through the applicationcontrol manager 46 designated key control and status informationrelating to the procedure then underway, as well as designated keycontrol and status information relating to the pumps, solenoids, valves,optical detectors, and other functional hardware of the system. ThePROCEDURE DRIVER task module 222 generates data containing thisregistered information, along with a date stamp to provide a time-basedcontext. The data are structured byte streams, which are furtherprocessed by the FILE SYSTEM task module 224 for storage, retrieval, ormanipulation.

[0115] The nature and type of the data that the PROCEDURE DRIVER taskmodule 222 generates can vary.

[0116] a. Procedure Data (the P Data)

[0117] In the illustrated embodiment, the PROCEDURE DRIVER task module222 registers all scanned bar code input, which can comprise, e.g.,information identifying the donor, the processing instrument, anddisposable components used for processing. The PROCEDURE DRIVER taskmodule 222 also registers from the application control manager all keyprocessing parameter and blood component yield values, as they areinitialized and as they are updated during the course of the procedure.

[0118] The PROCEDURE DRIVER task module 222 also registers allprocessing mode changes as well as all warning alarms generated. In theillustrated embodiment, the PROCEDURE DRIVER task module 222 alsoregisters designed special processing events, e.g., the start and stopof needle priming, as well as the pausing and resumption of a procedure.

[0119] The PROCEDURE DRIVER task module 222 establishes and maintains arandom access data file, called Act_Proc_Data (designated 234 in FIG.7). The contents of Act_Proc_Data file 234 comprise selected control andprocessing parameters. In the illustrated embodiment, the Act_Proc_Datafile 234 is a fixed length file, which is formatted as a template tohold data in a prescribed order. Active procedure data is periodicallywritten (e.g., every 15 seconds) to designated locations in the templateof the Act_Proc_Data file 234.

[0120] The current Act_Proc_Data file 234 therefore reflects the realtime status of significant control and processing parameters and datafor the procedure then underway. The parameters and data retained by theAct_Proc_Data file 234 can include, e.g., (I) donor identificationinformation (e.g., an assigned donor I.D. number, donor sex and weight,an assigned blood donation I.D. number, and selected blood processingprocedure); (ii) identification of the instrument and the disposablecomponents used for processing (e.g., by assigned instrument number anddisposable kit code, lot number, and expiration date); (iii) initialprocessing parameter values derived (e.g., anticoagulant ratio, plateletprecounts, whole blood hematocrit, whole blood volume to be processed,volume of plasma to collect, platelet yield, mean platelet volume,storage volume of plasma for the platelets collected, volume of citratereturned to the donor, etc.); and (iv) then active procedure data (e.g.,anticoagulant and saline used, anticoagulant and saline present inproduct and storage plasma, the collection time of the procedure, amountof WB processed, total WB drawn, total plasma storage and product plasmacollected).

[0121] In the illustrated embodiment, at the end of the procedure (and,if desired, periodically during the procedure (e.g., every 15 seconds)),the PROCEDURE DRIVER task module 222 generates time stamped proceduredata 236, which, in shorthand, are called “P Data” in FIG. 7). Theprocedure data 236 is a snap-shot of the information held in thethen-current Act_Proc_Data file 234.

[0122] The procedure data 236 is formatted according to the template ofthe Act_Proc_Data file 234. The current procedure data 236 contains asynopsis of key donor data, instrument and disposable data, targetedprocedure processing values, and actual procedure processing values.FIG. 14 exemplifies the nature and type of information contained in arepresentative procedure data file 236, in a written report format, aswill be described later.

[0123] The PROCEDURE DRIVER sends generated procedure data 236 to theFILE SYSTEM task module 224, which processes the data on the storagedevice 204 in a designated secure file structure for storage, retrieval,and manipulation. Further details of the FILE SYSTEM task module 224will be described later.

[0124] b. Event Data (the E Data)

[0125] During the course of the procedure, the PROCEDURE DRIVER taskmodule 222 can also generate other discrete types of data. For example,in the illustrated embodiment (see FIG. 7), the PROCEDURE DRIVER taskmodule 222 periodically generates time stamped event data 238, whichtogether build a chronological record of key processing events.

[0126] Event data 238, which, in shorthand, are called “E Data” in FIG.7, can be generated in response to the occurrence of key events, e.g.,marking the start of the procedure, the installation of disposablecomponents, the entry of processing parameters, priming, the entry ofdata scanned by the bar code scanner 214, alarm conditions and theirresolution, and the end of the procedure. Other event data 238 can alsobe generated periodically (e.g., every 15 minutes) to providethen-current processing parameters, e.g., the volume of whole bloodprocessed, the whole blood flow rate, whole blood inlet pump pressure,red blood cell return pump pressure.

[0127] The PROCEDURE DRIVER task module 222 communicates event data 238to the FILE SYSTEM task module 224. As will be described in greaterdetail later, the FILE SYSTEM task module 224 incorporates the eventdata 238 into the designated file structure on the storage device 204.The stored system event data 238, when arranged in chronologic order byfile time stamp, comprise a time-order record of significant procedureevents and conditions. FIG. 15 exemplifies the nature and type ofinformation contained in a compilation of representative event datafiles 238, in a written report format, as will be described later.

[0128] c. System Condition Data (the S Data)

[0129] In the illustrated embodiment (see FIG. 7), during the course ofthe system operation, system tasks also generate time stamped systemcondition data 336, which, in shorthand, are $$ called “S Data” in FIG.7. The system condition data represent preselected states, status, orerror conditions relating to the pumps, solenoids, valves, opticaldetectors, and other functional hardware of the system under the controlof the instrument manager 50.

[0130] The PROCEDURE DRIVER task module 222 communicates systemcondition data 336 to the FILE SYSTEM task module 224. As will bedescribed in greater detail later, the FILE SYSTEM task module 224incorporates the system condition data 336 into the designated filestructure on the storage device 204. The stored system condition data336 comprise time-order records of significant system hardware-relatedconditions during the course of the procedure. FIG. 17 exemplifies thenature and type of information contained in a compilation ofrepresentative system condition data 336, when formatted for viewing byan operator, as will be described later.

[0131] d. The Dump Sensor Data (the D Data)

[0132] In the illustrated embodiment (see FIG. 7), periodically duringthe course of the procedure (e.g., every 5 seconds), the PROCEDUREDRIVER task module 222 generates discrete time stamped dump sensor data350, which, in shorthand, are called “D Data” in FIG. 7. The dump sensordata 350 are snapshots of current sensed values recorded by conditionsensing hardware coupled to the controller 18. The condition sensinghardware can monitor, e.g., inlet and outlet pump pressures, weights ofblood collection containers, and optical transmission values sensed byoptical detectors.

[0133] The PROCEDURE DRIVER task module 222 communicates dump sensordata 350 to the FILE SYSTEM task module 224. As will be described ingreater detail later, the FILE SYSTEM task module 224 incorporates thedump sensor data 350 into the designated file structure on the storagedevice 204. The dump sensor data 350 comprise a time-order record ofsensed conditions monitored during the course of a given procedure.

[0134] ii. The FILE SYSTEM Task

[0135] The FILE SYSTEM task module 224 provides file services for thePROCEDURE DRIVER task module 222, the DATA EXCHANGE task module 228, andthe REPORT task module 226. It provides the interface for storage,retrieval, and manipulation of the procedure data 236, the event data236, the system condition data 336, and the dump sensor data 350.

[0136] As FIG. 8 shows, the FILE SYSTEM task module 224 includes a blockdevice function 240. The block device function 240 formats the media 242of the storage device 204 to have N blocks, each addressable by a numberstarting from 0 and going up to but not including N (in FIG. 8, N=43).The format structure includes a root node 244, which occupies block 0,with a redundant copy 244C in block 1. The format structure furtherincludes a directory node 246, which occupies one or more blocksbeginning with block 2. The format structure allocates the remainingblocks, up to but not including block N, as space for the various data236, 238, 336, and 350 generated by the PROCEDURE DRIVER task module222.

[0137] The block device function 240 statically divides the remainingblocks into discrete file spaces, which are each allocated to accept onetype of data 236, 238, 336, or 350. FIG. 8 shows, for the purpose ofillustration, four file spaces 248, 250, 252, and 254, for the fourtypes of data 236, 238, 336, and 350, respectively. However, there aretypically more blocks available, and additional file spaces cantherefore be allocated.

[0138] Each file space 248, 250, 252, and 254 comprises a contiguousrange of blocks. In the illustrated embodiment (FIG. 8), each file space248, 250, 252, and 254 has, for the purpose of illustration, the samemaximum size of 10 blocks. However, the data 236, 238, 336, and 350 willimpose different size requirements, and the file spaces 248, 250, 252,and 254 will typically have different maximum sizes.

[0139] a. The Root Node

[0140] The root node 244 identifies the name of file system anddescribes the overall layout geometry imposed by the runtime code. Theroot node 244 specifies the total capacity of the file system in blocksand the maximum number of fixed size files that may be used, i.e., howmany statically allocated file spaces exist (which, in the illustratedembodiment, is four). The root node 244 also includes a copy of thetemplate that was used by the PROCEDURE DRIVER task module 222 to createthe procedure data 236. The template is stored in the root node 244principally for informational purposes. Still, the stored template couldbe used as a reference to reconstruct the file system, should radicaldamage occur.

[0141] The root node 244 contains no modifiable information. It is nevermodified once the file system is created. An identical copy 244C of theroot node 244 is kept in block 1, in case block 0 becomes unreadable.

[0142] b. The Directory Node

[0143] After the media 242 has been formatted by the block devicefunction 240, it has the ability to accommodate a fixed number of filesspaces, each having a fixed maximum predetermined size. The directorynode 246 comprises a directory table 256 for the formatted file spaces248, 250, 252, and 254.

[0144] As exemplified in FIG. 9, the directory table 256 lists thestarting block address and fixed size of each file space. The table 256includes a directory element 258, or “slot,” for every preallocated filespace in the file system (of which there are four in the illustratedembodiment) Each directory element 258 contains the block number (i.e.,address) of a preallocated file space and the preallocated size of thefile space in units of blocks.

[0145] As described herein, the block numbers or addresses retained inthe directory table 256 refer to the logical file system blockaddresses, which may or may not correspond to physical media blockaddresses.

[0146] The directory table 256 contains only one directory level, i.e.,the directory table 256 is not hierarchical. The directory table 256also is not dynamic. It is never modified once a file system has beencreated. The table 256 serves simply to provide static pointers to thelocation of the allocated file spaces.

[0147] The directory table 256 also does not indicate whether or not apreallocated file space contains data or is available. Dynamicallocation information is kept on the byte-stream data written to thefile spaces, i.e., the presence or absence of data itself provides theallocation information for the file space.

[0148] The FILE SYSTEM task module 224 as described retains theintegrity of the block file system structure, despite power failure orarbitrary corruption of data on the storage device 204. In the face ofsuch abuse, the FILE SYSTEM task module 224 will not lose the basicblock structure of the file system, nor will it require a distinct filesystem repair operation to be performed. Each file space 248, 250, 252,and 254 has a fixed maximum size, and the file space cannot grow toaccommodate more data. Any allocation of file spaces inconsistent withthe directory table 256 can be fixed on the fly.

[0149] The block device function 240 also includes a hard safety checkthat does not allow writes to block numbers less than the firstpreallocated file space, once the file system has been created. Thelow-numbered blocks are only activated for writing during file systemcreation. Therefore it is unlikely that a software bug could destroy thedirectory blocks. Since the directory blocks are static, it is alsounlikely they could be destroyed by a write error during power failure.

[0150] C. Data Spaces

[0151] As FIG. 10 shows, each file space 248, 250, 252, and 254 includesa primary node 260. The primary node 260 contains metadata associatedwith the file space (i.e. allocated or free, file name, creation time,current size, etc.). Each file space also includes a secondary node 262.The secondary node 262 has the same contents as the primary node 260.This is used for “flip-flopping” while updating a file's metadata, aswill be described later.

[0152] Each file space 248, 250, 252, and 254 also includes the files'spreallocated physical space 264. The space 264 accepts the data contentsof allocated procedure data 236, event data 238, system condition data336, or dump sensor data 350.

[0153] The block device function 240 performs no random access writes.The block device function 240 allows either the reading and writing ofwhole blocks addressed by beginning block number, or the successiveappending of data forward in the file space until the file space isfilled.

[0154] As implemented in the illustrated embodiment, at the outset of agiven procedure, one file space 248 is reserved for the procedure data236 generated during the procedure, and one file space 250 is reservedfor all event data 236 generated during the procedure. Upon the firstboot-up of the data interface 202, one file space 252 is designated forsystem condition data 336 for all subsequent procedures, and one filespace 254 is designated for dump sensor data 350 for all subsequentprocedures. As will be described in greater detail later, the filespaces 252 and 254 hold ringfiles, to which the newest designated data336 and 350 are appended, overwriting the oldest data.

[0155] (1) The Procedure Data File Space

[0156] The maximum size of the reserved procedure data file space 248 isselected to comfortably accommodate the entire template of the proceduredata 236, plus a backup copy (as described later). In a representativeembodiment, a maximum file size of about 5.6 kilobytes is reserved.

[0157] The reserved procedure data file space 248 receives the firstprocedure data 236 generated by the PROCEDURE DRIVER task module 222 atthe outset of a procedure. Subsequent procedure data 236 generated bythe PROCEDURE DRIVER task module 222 during the course of the procedureare written as a block to the same procedure file space 248, beginningat logical offset zero of the file space 248, thereby overwriting thepreceding procedure data in its entirety. Conceptually, the proceduredata 236 in the file space 248 is periodically “refreshed” as theprocedure progresses, until the procedure ends, which leaves thelast-written procedure data 236 in the space 248.

[0158] (2) The Event Data File Space

[0159] The maximum size of the reserved event data file space 250 isselected to comfortably accommodate all event data 238 generated duringa typical procedure, plus backup copies (as described later). In arepresentative embodiment, a maximum file size of about 66.5 kilobytesis reserved.

[0160] The reserved event data file space 250 receives at logical offsetzero, the first event data 238 generated by the PROCEDURE DRIVER taskmodule 222 at the outset of a procedure. The next event data 238 isappended at the end of file (EOF) point of the first event data 238.Successive event data 238 are appended in this fashion, until physicaldata space 250 is filled, after which no more event data can be recordedfor the procedure.

[0161] Should the data space 250 fill to its fixed capacity, the FILESYSTEM task module 224 generates a message output to the USER INTERFACEtask module 230 (to be described later). The assessment of the maximumsize of the event data file space 250 should be carefully made, toassure that event data are not lost near the end of a given procedure.The block device function 240 can, as a back up, also include a functionthat designates a second event file space, should an atypical procedureoccur that generates an atypical number of event data to fill the firstevent file space 250.

[0162] (3) The System Condition Data File Space and the Dump Sensor FileSpace (Ringfiles)

[0163] In like fashion, the block device function 240 writes andsuccessively appends system condition data 336 and dump sensor data 350in the designated reserved file spaces, respectively, 252 and 254.However, unlike the file space 250, which allows no further data entrywhen its physical data space is filled, the block device function 240includes a function 266 that accommodates continuous appending of systemcondition data 336 and dump sensor data 350 in their respective fixedfile spaces 252 and 254. The function 266 treats the fixed physicalallocated space 264 for these spaces 252 and 254 as a circular ring, orringfile 268 (see FIG. 11). In a ringfile 268, the oldest data 270 isoverwritten with new data 272 after the file space 264 is filled.

[0164] The ringfile function 266 initially appends all data (which, forthe purpose of illustration in FIG. 11, are system condition data 336)generated by the PROCEDURE DRIVER task module 222 during a givenprocedure in the designated file space 264. As the data 336 aresuccessively written to the designated file space 264, the size of theringfile 268 starts at zero for the first data 336 and grows asadditional data 336 are appended, until the file space 264 becomes full.At this point (see FIG. 11), the ringfile function 266 “wraps” the databy overwriting old data 270 with new data 272 beginning at the firstnode allocated to data in the file space 264 (that is, after the primaryand secondary nodes 260 and 262, which carry the metadata).

[0165] A ringseam 274 separates the oldest data 270 in the file space264 and the newest data 272 in the file space 264. As new data 272enters the file space 264, the ringseam 274 continuously moves towardthe end of the preallocated space (as indicated by arrow 276 in FIG.11). Once the end of the file space 264 is reached, the ringseam 274wraps around to first data node and again moves forward toward the endof the file space 264.

[0166] Following the first wrap of data in the file space 264, theringfile function 266 maintains a logical ringseam pointer 278. Theringseam pointer 278 marks the block address of the ringseam 274. Theringfile function 266 also locates the file's logical end-of-filepointer 280 at the block address that marks the logical junction betweenthe newest data 272 and the ringseam pointer 278. The ringseam function266 also places the logical offset zero pointer 282 at the block addressthat marks the logical junction between the oldest data 270 and theringseam pointer 278. Following the first wrap of data, the ringseamfunction 266 appends data beginning at the logical end of file pointer280. As the appended data is written to the file space 264, the ringseamfunction 266 advances the logical offset zero pointer 282 in tandem withthe ringseam pointer 278.

[0167] The fixed maximum size of the system condition data file space252 and dump sensor data file space 254 are selected to comfortablyaccommodate an expected compilation of data, plus backup copies (asdescribed later). In a representative embodiment, a maximum file size ofabout 100 kilobytes is reserved for the system condition data file space252, and a maximum file size of about 1 megabytes is reserved for thedump sensor data file space 254.

[0168] (4) File Space Integrity

[0169] The block device function 240 automatically creates backup copiesof the data 236, 238, 336, and 350 written to the respective file spaces248, 250, 252, and 254. Furthermore, data structures in all allocatedfile spaces are protected per-block by a 16-bit CRC. This allows theblock device function 240 to detect if a block was successfully writtenand whether it is valid when read back. If a block is found to beinvalid for any reason, including a CRC mismatch, the block devicefunction 240 verifies the backup copy of the block. If valid, the blockdevice function 240 proceeds using the data in the backup copy, or thebackup data can be used to repair the damaged block.

[0170] The most dynamic aspect of the file system is the file node 260of a given file space. Whenever data is appended to a file space, orwritten to a file space, the metadata of the file space must be updated.The last modified time must be updated to the current time. If appended,the logical size of the file must be increased by the amount of dataappended. The current read or write position must also be updated toindicate where the next read or write operation should occur.

[0171] Because the file node 260 is updated so frequently, and because afile node 260 is crucial when accessing a file, each file space 248,250, 252, and 254 includes the secondary file node 262. Each file node260 and 262 has an “age” marker, which is initialized at zero when a newfile is created in the file space. Each time the file node 260 and 262of the file space is modified, the file node's age marker isincremented.

[0172] Whenever a file's metadata must be updated, the block driverfunction 240 registers the file node's age marker. If the age marker isan even number, the primary file node 260 is modified. Conversely, ifthe age marker is an odd number, the secondary file node 262 ismodified. Writes to the file nodes 260 and 262 are thereby“flip-flopped” between the primary and secondary file nodes 260 and 262.

[0173] When the device block function needs to read a file node, itreads both primary and secondary file nodes 260 and 262 and considersthe one with the highest “age” marker to be valid. This allows a filenode update operation (i.e. a write to a file node) to experience ahardware failure, in which the entire file node is destroyed. Thealternate file node will always contain a consistent, albeit older,state of the file.

[0174] The ability to withstand abuse does not extend to data containedin each procedure or event data 236 or 238. It is the responsibility ofthe PROCEDURE DRIVER task module 222 and FILE SYSTEM task module 224 tomaintain data integrity. However, as a general rule, data loss willoccur at the tail of the file when it is appended in a forwarddirection. Thus, should an error occur in an append operation, itaffects only the most recently appended data, which represents arelatively small portion of the overall file.

[0175] The FILE SYSTEM task module 224 maintains file integrity withoutresort to conventional complex data base management functions, such asjournalling-file systems, or a commit-rollback transaction facility. Bynot allowing formatted file spaces to grow, the FILE SYSTEM task module224 requires only small modifications to the file system metadata asdata is written. The FILE SYSTEM task module 224 does not rely upon afile directory that dynamically points to where each file is located.The FILE SYSTEM task module 224 does not move blocks that contain filesystem data and then update pointers to refer to their new location. TheFILE SYSTEM task module 224 does not dynamically extend the size of thefile by removing blocks from a free pool and attaching them to the file,or dynamically return a file's blocks to the free pool and unlinking thefile from the file directory. The FILE SYSTEM task module 224 minimizesthe windows of time during which the file system is being dynamicallyaltered, and during which time a file system is vulnerable tocatastrophic data corruption due to power failure. By minimizing thetime of vulnerability, the FILE SYSTEM task module 224 minimizes thechance of catastrophic corruption of data, should power failure occur.

[0176] iii. The USER INTERFACE Task (File System Task Support)

[0177] The USER INTERFACE task module 230 links the FILE SYSTEM taskmodule 224 and the REPORT task module 226 to the interface manager 66,which has been previously described. The USER INTERFACE task module 230sends to the interface manager 66 abstract Create_Display# commandsprescribed to support the data interface 202. The interface manager 66processes the data interface 202 Create_Display# commands to generatespecific Format_Display# commands. As before described theFormat_Display# commands control the particular format, attributes, andprotocols necessary to create, refresh, and close the visual display onthe interface screen 60. The USER INTERFACE task module 230 therebyprovides the data interface 202 with a graphical user interface.

[0178] In the illustrated embodiment (see FIG. 4), the Main Menu displayshown by default in the working region 70 of the screen 60 includes aSPECIAL FEATURES button field 96. When touched, the SPECIAL FEATURESbutton field 96 calls up a function that displays a Special FeaturesSubmenu in the working region 70, as FIG. 6A shows. The Features Submenulists in an array of touch selectable button fields 200. One of thebutton fields 284 on the Special Features Submenu is labeled DIAGNOSTIC.

[0179] When DIAGNOSTIC button field 284 is pushed, the USER INTERFACEtask module 230 generates a prescribed Create_Display# command to theinterface manager 66, which, in turn, generates a Format_Display#command to display a File Manger Submenu in the working region 70, asFIG. 6B shows. The File Manager Submenu lists in an array of touchselectable button fields 352. One of the button fields 354 is labeledFILESYSTEM UTILITIES.

[0180] a. Filesystem Utilities

[0181] When the FILESYSTEM UTILITIES button field 354 is pushed, theUSER INTERFACE task module 230 generates a prescribed Create_Display#command to the interface manager 66, which, in turn, generates aFormat_Display# command to display a File System Information Submenu, asshown in FIG. 12.

[0182] The File System Information Submenu includes a first box 286,which identifies the attributes of the storage device 204 of the datainterface 202, e.g., by vendor, model, capacity, and by confirming itsinstallation. This information is provided to the USER INTERFACE taskmodule 230 by the FILE SYSTEM task module 224. The File SystemInformation Submenu also includes a second box 288, which identifies theattributes of the FILE SYSTEM task module 224 itself, e.g., byidentifying the software version of the FILE SYSTEM task module 224which is installed, by confirming its operational readiness, and bylisting its present capacity.

[0183] The File System Information Submenu also includes a push buttonfield 290 labeled FILE MANAGER. When the FILE MANAGER button field 290is pushed, the USER INTERFACE task module 230 generates a prescribedCreate_Display# command to the interface manager 66, which, in turn,generates a Format_Display# command to display a File Directory Submenu,as FIG. 13 shows.

[0184] The File Directory Submenu includes a box field 292. The USERINTERFACE task module 230 commands the FILE SYSTEM task module 224 toread the current metadata file node 260 or 262 of each allocatedprocedure file space 248 and event file space 250. The USER INTERFACEtask module 230 formats the metadata into file system data 294, which islisted in rows in the box field 292 by E (Event Data) or P (ProcedureData) suffix, time stamp, and file size residing in the storage device204. The operator can scroll using control buttons 296, up and down therows in known fashion.

[0185] The File Directory Submenu also includes sort-option push buttonfields 298, 300, and 302, labeled, respectively, SORT BY NAME, SORT BYDATE, and SORT BY SIZE. When a sort-option is selected, the USERINTERFACE task module 230 reformats the listing in the box field 292 toarrange the file order accordingly, by name, by date, or by size.

[0186] The USER INTERFACE task module 230 commands the display of ahighlight 304 in the File Directory Submenu to allow a user to select afile row. The File Directory Submenu includes a DELETE push button field306. When the DELETE button field 306 is pushed, the USER INTERFACE taskmodule 230 commands the FILE SYSTEM task module 224 to delete the datacontents of the highlighted file space from the storage device 204. Thisfrees the file space for receiving data for another procedure.

[0187] The File Directory Submenu also includes an EXIT push buttonfield 308. When the EXIT button field 308 is pushed (or whenever theMAIN MENU button field 82 visible in the status region 68 is pushed),the USER INTERFACE task module 230 returns the display in the workingregion 70 back to the default Main Menu, as shown in FIG. 4.

[0188] b. System Log Viewer

[0189] Another button field 360 on the File Manager Submenu is labeledSYSTEM LOG VIEWER. When the SYSTEM LOG VIEWER button field 360 ispushed, the USER INTERFACE task module 230 generates a prescribedCreate_Display# command to the interface manager 66, which, in turn,generates a Format_Display# command to display a Log Viewer Submenu, asshown in FIG. 17.

[0190] The Log Viewer Submenu includes a box field 362. The USERINTERFACE task module 230 commands the FILE SYSTEM task module 224 toread the system condition data 336 contained in the allocated ringfilespace 252. The USER INTERFACE task module 230 formats the systemcondition data 336 to display their contents in chronological order byrow in the box field 362. Each row lists, e.g., a description of thestate, condition, or error recorded, with a time stamp, and anidentifying system reference code. Other information contained in thedata 336 can also be listed. The operator can scroll using controlbuttons 364, up and down the rows in known fashion.

[0191] When the MAIN MENU button field 82 visible in the status region68 is pushed, the USER INTERFACE task module 230 returns the display inthe working region 70 back to the default Main Menu, as shown in FIG. 4.

[0192] c. Bar Code Display

[0193] While the USER INTERFACE task module 230 issues commands tochange the working region 70 of the screen 60 to display file directoryinformation and functions (FIGS. 12 and 13), or the system conditionevent log (FIG. 17), the status region 68 of the screen 60 continues tosimultaneously show its information. The MINOR MODE field 76 continuesto show that the procedure is in the collection mode, and the statusregion continuously shows in the WB PROCESSED FIELD 78 the volume of WBdrawn from the donor. The location and attributes of the other buttonfields 80/82/84/86 remain unchanged, unless the procedure changesoperational mode, at which time the MINOR MODE field 76 will change toreflect this mode change.

[0194] The USER INTERFACE task module 230 also communicates with the BARCODE task module 220. The USER INTERFACE task module 230 receives thefeedback message 232 generated by the BAR CODE task module 220 uponconfirming acceptance of bar code-scanned input (see FIG. 7). As FIGS.12, 13, and 20 show, the USER INTERFACE task module 230 commands thedisplay of the feedback message in the a BAR CODE field 358 provided inthe status region 68 of the screen 60.

[0195] iv. The REPORT task

[0196] The REPORT task module 226 communicates with the printer portlink 212. The REPORT task module 226 is serviced by the FILE SYSTEM taskmodule 224 and the USER INTERFACE task module 230. When active, theREPORT task module 226 directs the FILE SYSTEM task module 224 to locateand read designated procedure and event data 236 and 238 then-residingin the storage device 204. The REPORT task module 226 builds reportspresenting the data in prescribed alphanumeric format, which FIGS. 14and 15 exemplify. The REPORT task module 226 downloads the report to theprinter 216.

[0197] The format and contents of printed reports can, of course, vary.For example, the REPORT task module 226 can generate a Procedure Report310 (see FIG. 14), which is built upon a procedure data 236 contained ina given procedure data file space 248 on the storage device 204. Asanother example, the REPORT task module 226 can generate an Event Report312 (see FIG. 15), which lists in time order the contents of the eventdata stored in a given event data file space 250 on the storage device204.

[0198] V. The USER INTERFACE Task (REPORT Task Support)

[0199] The USER INTERFACE task module 230 also links the REPORT taskmodule 226 to the interface manager 66. In the illustrated embodiment,one of the button fields 314 on the Special Features Submenu (see FIG.6A) (which is accessed through SPECIAL FEATURES button field 96 on theMain Menu display, shown in FIG. 4) is labeled PRINT PROCEDURE REPORTS.When the PRINT PROCEDURE REPORTS button field 314 is pushed, the USERINTERFACE task module 230 generates a prescribed Create_Display# commandto the interface manager 66, which, in turn, generates a Format_Display#command to display a Print Procedure Reports Submenu, shown in FIG. 16.

[0200] The Print Procedure Reports includes a box field 316, which listsby row the procedures for which current procedure and event data 236 and238 reside on the storage device 204. The operator can scroll usingcontrol buttons 318, up and down the rows in known fashion. The USERINTERFACE task module 230 displays a highlight 320 to make a selection.

[0201] The Print Procedure Reports Submenu includes a PRINT SELECTEDREPORT push button field 322. When pushed, the USER INTERFACE taskmodule 230 commands the REPORT task module 226 to format and print theformatted reports for the selected procedure (which, in the illustratedembodiment, are the Procedure Report 310 shown in FIG. 14 and the EventReport 312 shown in FIG. 15. By selected a CANCEL CURRENT REPORT pushbutton 324 field, the user can terminate printing of the selectedreports.

[0202] The Print Procedure Reports Submenu also includes a PrinterStatus box field 326. The Printer Status box field 326 displaysinformation from the COMMUNICATION MANAGER task module 218 that reportsstatus of the printer 216, e.g., Idle, Busy, Error.

[0203] When the MAIN MENU button field 82 visible in the status region68 is pushed, the USER INTERFACE task module 230 returns the display inthe working region 70 back to the default Main Menu, as shown in FIG. 4.

[0204] The USER INTERFACE task module 230 also allows the operator tocondition the REPORT task module 226 to automatically compile and printthe Procedure Report 310 and Event Report 312 at the conclusion of aprocedure. In the illustrated embodiment (see FIG. 6A), one of thebutton fields 330 on the Features Submenu is labeled SYSTEMCONFIGURATION. When the SYSTEM CONFIGURATION button field 330 is pushed,the USER INTERFACE task module 230 generates a prescribedCreate_Display# command to the interface manager 66, which, in turn,generates a Format_Display# command to display a System ConfigurationSubmenu, as shown in FIG. 18. The System Configuration Submenu, in turn,includes a SET CONFIGURATION button 332, which, when pushed, causes thedisplay of a Set Configuration Submenu, as shown in FIG. 19. The SetConfiguration Submenu includes an “AutoPrint” push button field 334.Pushing the button 334 toggles the button label between Turn On and TurnOff.

[0205] When toggled to the Turn Off state (in which the autoprintfeature is actuated), the data interface 202 is conditioned toautomatically compile and print the Procedure Report 310 and EventReport 312 at the end of the procedure.

[0206] D. The DATA EXCHANGE Task

[0207] I. Data Transfer Function

[0208] It should be appreciated that, due to the features of thePROCEDURE DRIVER task module 222, the FILE SYSTEM task module 224, thePRINT task module, and the USER INTERFACE task module 230 alreadydescribed, the data interface 202 is fully integrated to store,retrieve, and manipulate data without the use of or connection to anexternal computer 206.

[0209] However, the second port 210 makes it possible, if desired, tolink the data interface 202 to an external computer 206. The DATAEXCHANGE task module 228 includes a data share function 384, whichestablishes a communication exchange interface between the on-board datainterface 202 and the external computer 206.

[0210] In one embodiment, the external computer 206 coupled to thesecond port link 210 can include its own resident control software 338(see FIG. 7). The software 338 is programmed to prompt the datainterface 202 for key control and processing parameters of a givenprocedure. The data share function 384 of the DATA EXCHANGE task module228 responds by assembling and downloading this data to the computer 206for storage, retrieval, or manipulation.

[0211] In this arrangement, the data share function 384 of the DATAEXCHANGE task module 228 generates a random access data file 340,designated Act2_Proc_Data in FIG. 7. Act2_Proc_Data file 340 isformatted the same as the Act_Proc_Data file 234 maintained in randomaccess memory by the PROCEDURE DRIVER task module 222. While a givenprocedure is underway, the data share function 384 periodically copiesdata from the Act_Proc_Data file 234 into the Act2_Proc_Data file 340.While a given procedure is underway, the data share function 384 canalso periodically read event data residing in the current event datafile space 250 on the storage device 204. However, while a givenprocedure is underway, the data share function 384 can not read thecurrent procedure data file space 248 on the storage device 204.

[0212] The control software 338 residing in the external computer 206sends programmed ASCII input to the data share function 384 as theprocedure progresses. In response to the programmed input, the datashare function 384 builds desired responses based upon data read fromthe Act2_Proc_Data file 340 or from the current event data file space250 on the storage device 204. The data share function 384 transmits theresponses to the external computer 206 for storage, retrieval, ormanipulation. Once a procedure is completed, the data share function 384can read data from both the procedure data file space 248 and the eventdata file space 250 on the storage device 204, to build responses topreprogrammed input from the external computer 206.

[0213] In the illustrated embodiment, the data share function 384 isautomatically activated whenever the COMMUNICATION MANAGER task module218 senses communication through the port 210 with a computer 206 havingthe enabling control software 338.

[0214] ii. Control Input Function

[0215] The DATA EXCHANGE task module 228 also includes a data controlfunction 386, by which process control input 388 can be received fromthe external computer 206. In this arrangement, the control software 338of the computer 206 establishes on the computer 206 a graphical userinterface compatible with the interface manager 66. The data controlfunction 386 transmits the process control input 388 from computer 206to the interface manager 66, via the USER INTERFACE task module 230. Theprocess control input 388 serves the same command and control functionsas corresponding input from the screen 60, as previously described.

[0216] The data control function 386 makes it possible to establish oralter processing parameters for the controller 18 from a remotelocation.

[0217] iii. Purge Function

[0218] In the illustrated embodiment, the DATA EXCHANGE task module 228includes a PURGE function 344. The PURGE function 344 performshouse-keeping on the number of files managed by the FILE SYSTEM taskmodule 224. At prescribed intervals (e.g., at the conclusion or eachprocedure), the PURGE function 344 reads the metadata file nodes 260/262maintained by the FILE SYSTEM task module 224. The PURGE functiondirects the FILE SYSTEM task module 224 to delete data from theprocedure and event data file spaces in excess of a prescribed numberaccording to where the oldest data exists. For example, if the FILESYSTEM task module 224 has allocated file space for forty (40)procedures (i.e., forty procedure data file spaces and forty event datafile spaces), the PURGE function 314 deletes the data in allocatedprocedure and event file spaces in excess of thirty (30) each, accordingto where the oldest data are stored. In this way, the data interface 202maintains current procedure and event data 236 and 238 for the thirty(30) most recent procedures. The ringfile nature of the system conditiondata 336 and dump sensor data 350 automatically assures that only recentdata is maintained.

[0219] In a representative implementation, the storage device 204 haseight megabytes of storage space. The block device function 240allocates two files spaces of 100 kilobytes each, one for the systemcondition data file space 252 and the other being an open extra filespace. The block device function 240 also allocates two files spaces of1 megabyte each, one for the dump sensor data file space 254 and theother being an open extra file space. The block device function 240further allocates 70 file spaces of 5.6 kilobytes each as procedure datafile spaces 248, and 70 file spaces of 66.5 kilobytes each as event datafile spaces 250. Controlled by the PURGE function 314, thirty each ofthese file spaces 248 and 250 hold the current procedure data. Theremaining thirty are free file spaces.

[0220] E. The USER INTERFACE Task (Data Exchange Task Support)

[0221] i. File Transfer Function

[0222] In another embodiment, procedure or event data files residing onthe storage device 204 can be transferred, or downloaded, in anyarbitrary order to any compatible external computer 206 linked to thesecond port, as controlled by the USER INTERFACE task module 230 of thedata interface 202, and without otherwise requiring control software onthe external computer 206.

[0223] As implemented in the illustrated embodiment, the File DirectorySubmenu (see FIG. 13) includes a TRANSFER push button field 346. Whenthe TRANSFER button field 346 is pushed, the USER INTERFACE task module230 commands the FILE SYSTEM task module 224 to copy data in thehighlighted file from the storage device 204 to the DATA EXCHANGE taskmodule 228. The DATA EXCHANGE task module 228, in turn, transfers thedata to the external computer 206 via the second port. The externalcomputer 206 can store, retrieve, and manipulate the data using on-boarddata processing software.

[0224] The integrated data recording function of the data interface 202does not require an external computer 206 connected during the datastorage process. Furthermore, any external computer 206 may be connectedafter the data has been stored by the data interface 202. The datainterface 202 also makes possible to download data to an externalcomputer 206 at an arbitrary time and in an arbitrary fashion after theprocessing function has been completed. Data collected by the datainterface 202 is also available to field service personnel, which allowsaccurate program diagnosis and instrument performance evaluation.

[0225] ii. File Import Function

[0226] In the illustrated embodiment (see FIG. 21), the DATA EXCHANGEtask module 228 includes an import function 380. The import function 380permits the import, or uploading, of additional operating algorithms 382from the external computer 206 into the controller 18 forimplementation.

[0227] In the illustrated implementation, the System ConfigurationSubmenu (FIG. 18) includes a IMPORT CONFIGURATION button 378, which,when pushed, activates an import function 380. The import function 380boots the MPU 44 of the controller 18 into an import mode, which isgoverned by the control software 338 of the computer 206 coupled to theport link 210. Governed by input from the computer 206, the controlsoftware 338 installs one or more additional operating algorithms 382 asprocess software in EPROM's in the MPU 44, and, in particular, theinstrument control manager 46, the instrument manager 50, and theinterface manager 66.

[0228] The imported algorithms 382 establish one or more newapplications that can be called up by the application control manager46. The imported algorithms also install implementing process softwarein the instrument manager 50 and interface manager 66.

[0229] F. The DATA DUMP Task

[0230] In the illustrated embodiment, the user interface 202 alsoincludes a DATA DUMP task module 366. The DATA DUMP task module 366communicates with the port link 348 and the FILE SYSTEM task module 224.The DATA DUMP task function 366 periodically reads the data contents ofthe file space (i.e., space 254 in FIG. 8), where the FILE SYSTEM taskmodule 244 writes the dump sensor data 350. The DATA DUMP task module366 formats the current dump sensor data 350 as a message buffer output370, which is transmitted through the port link 348 to a connectedexternal computer 206′.

[0231] The external computer 206′ includes enabling control software368. The software 368 conditions the computer 206′ to receive theformatted message buffer output 370 for storage, retrieval, ormanipulation.

[0232] For example, the DATA DUMP task module 366 can automaticallyassemble and transmit a message buffer output 370 every five seconds tothe port link 348, for download to the external computer 206′. Thistime-sequential record, maintained by the external computer 206′provides an accurate, comprehensive account of sensed conditionsthroughout the procedure. This record can be used by service ordiagnostic technicians to troubleshoot system errors. This record canalso aid research and development technicians in designing, developing,and implementing new operating algorithms for the application controlmanager 46.

[0233] In FIG. 20, the DATA DUMP task module 366 includes a predictorfunction 372. The predictor function 372 includes algorithms whichanalyze the contents of successive message buffer outputs 370 accordingto predetermined criteria. For example, the criteria can gauge sensedconditions with respect to compliance with established operating ranges.The criteria can assess changes in sensed conditions over time, usingproportional, integral, or derivative analyses, or combinations thereof.The criteria can compare the sensed conditions with respect to otherempirically developed standards or test algorithms, using, for example,correlation or fuzzy logic techniques.

[0234] On the basis of its analyses, the predictor function 372generates diagnostic output files 374. The diagnostic output files 374indicate system performance trends and predict potential system errorsor failures before they occur.

[0235] The output files 374 are managed by the FILE SYSTEM task module224 in the same manner as, for example, the system condition data files336, for viewing through the USER INTERFACE task module 230 with thesystem condition data files 336. FIG. 17 shows the inclusion of adiagnostic notice 376 based upon a diagnostic output file 374, whichidentifies an adverse performance trend and recommends a service checkbefore failure occurs. Alternatively, or in combination, the contents ofa diagnostic output file 374 could be included as an item in the EventReport 312, handled through the REPORT task module 226.

[0236] Alternatively, or in combination, the enabling control software368 of the external computer 206′ can incorporate the predictor function372. In this arrangement, the external computer 2061 can provide its owndiagnostic notice 376 in visual or hard copy form.

[0237] The data interface 202 and graphical interface as described canbe realized, e.g., as a “C” language program implemented using the MSWINDOWS™ application and the standard WINDOWS 32 API controls, e.g., asprovided by the WINDOWS™ Development Kit, along with conventionalgraphics software disclosed in public literature.

[0238] Various features of the invention are set forth in the followingclaims.

We claim:
 1. A blood processing system comprising a device includingprocessing hardware to carry out a blood processing procedure, aprocessing manager residing on the device to monitor status conditionsduring the blood processing procedure, and a data interface residing onthe device including a data generator task to generate data based uponmonitored status conditions, a flash memory data storage medium, and afile manager task to write the data to the flash memory data storagemedium.
 2. A system according to claim 1 wherein the flash memory datastorage medium includes a block file space, to which the data is writtenby the file manager task.
 3. A system according to claim 2 wherein thefile manager task appends the data to the block file space.
 4. A systemaccording to claim 2 wherein the file manager task overwrites old datain the block file space with new data.
 5. A system according to claim 2wherein the block file space has a fixed maximum size.
 6. A systemaccording to claim 5 wherein the file manager task appends the data tothe block file space until the fixed maximum size is reached.
 7. Asystem according to claim 6 wherein the file manager task generates anoutput when the fixed maximum size is reached.
 8. A system according toclaim 5 wherein, when the fixed maximum size is exceeded, the filemanager task appends the data to the block file space by overwritingoldest data with newest data.
 9. A system according to claim 1 whereinthe data interface includes a print task coupled to the file managertask to print data written to the flash memory storage medium.
 10. Asystem according to claim 1 wherein the data interface includes a viewtask coupled to the file manager task to view data written to the flashmemory storage medium.
 11. A system according to claim 1 wherein thedata interface includes an exchange task coupled to the file managertask to offload data from the flash memory storage medium.
 12. A systemaccording to claim 1 wherein the data interface includes a system taskcoupled to the file manager task for manipulating data written to theflash memory storage medium.
 13. A system according to claim 1 whereinthe flash memory data storage medium includes a block file space, towhich the data is written by the file manager task, the block file spaceincluding a node to record metadata for the block file space.
 14. Asystem according to claim 13 wherein the data interface includes asystem task for viewing the metadata.
 15. A blood processing systemcomprising means for monitoring status conditions over time during ablood processing procedure, means for generating data based uponmonitored status conditions, and means for writing the data to a flashmemory storage medium.
 16. A system according to claim 15 and furtherincluding means for manipulating the data written to the flash memorystorage medium.
 17. A system according to claim 15 and further includingmeans for retrieving the data written to the flash memory storagemedium.
 18. A blood processing system comprising a device includingprocessing hardware to carry out a blood processing procedure, aprocessing control manager residing on the device to monitor statusconditions during the blood processing procedure, a data interfaceresiding on the device including a data storage medium having first andsecond block file spaces to receive data, a data generator task togenerate discrete first and second data streams based upon statusconditions monitored over time, and a file manager task to append eachfirst data stream chronologically to the first block file space and tooverwrite each second data stream in succession in the second block filespace.
 19. A system according to claim 18 wherein the data interfaceincludes a print task element coupled to the file manager task tocompile data in at least one of the block files for printing.
 20. Asystem according to claim 19 wherein the print task formats the complieddata for printing as a prescribed report.
 21. A system according toclaim 18 wherein the data interface includes a view task coupled to thefile manager task to compile data in at least one of the block files forviewing.
 22. A system according to claim 18 wherein the data interfaceincludes an exchange task coupled to the file manager task to offloaddata from at least one of the block files.
 23. A system according toclaim 18 wherein the data interface includes a system task coupled tothe file manager task for manipulating data written to at least one ofthe block files.
 24. A system according to claim 18 wherein the firstblock file has a fixed maximum size, and wherein the file manager taskappends the first data streams chronologically to the first block filespace until the fixed maximum size is reached.
 25. A system according toclaim 24 wherein the file manager task generates an output when thefixed maximum size is reached.
 26. A system according to claim 18wherein the first block file has a fixed maximum size, and wherein, whenthe fixed maximum size is exceeded, the file manager task appends byoverwriting oldest first data streams with newest first data streams.27. A system according to claim 18 wherein both the first and secondblock file spaces have fixed maximum sizes.
 28. A system according toclaim 18 wherein the data storage medium comprises a flash memorystorage device.
 29. A blood processing system comprising a deviceincluding processing hardware to carry out a blood processing procedure,a processing control manager on the device coupled to the processinghardware to monitor status conditions over time during the bloodprocessing procedure, and a data interface on the device coupled to theprocessing control manager including a data storage medium including afile space formatted to a fixed maximum size, a data generator task togenerate chronologic data streams based upon status conditions monitoredover time, and a file manager task to append the chronologic datastreams to the file space in chronologic order and to read thechronologic data streams from the file space as a chronologic blockfile.
 30. A system according to claim 29 wherein the data interfaceincludes a print task coupled to the file manager task to compile datain the chronologic block file for printing.
 31. A system according toclaim 29 wherein the data interface includes a view task coupled to thefile manager task to compile data in the chronologic block file forviewing.
 32. A system according to claim 29 wherein the file managertask appends chronologic data streams to the file space until the fixedmaximum size is reached.
 33. A system according to claim 32 wherein thefile manager task generates an output when the fixed maximum size isreached.
 34. A system according to claim 29 wherein the file managertask appends chronologic data streams to the file space by overwritingoldest data streams with newest data streams.
 35. A system according toclaim 29 wherein the data storage medium comprises a flash memory'storage device.
 36. A blood processing system comprising a deviceincluding processing hardware to carry out a blood processing procedure,a processing control manager on the device coupled to the processinghardware to monitor status conditions over time during the bloodprocessing procedure, and a data interface on the device coupled to theprocessing control manager including a data storage medium including afile space formatted to a fixed maximum size, a data generator task togenerate a time-specific data stream based upon status conditions at apoint in time, and a file manager task to write the time-specific datastream to the file space as a time-specific block file and to read thetime-specific data stream from the file space as the time-specific blockfile.
 37. A system according to claim 36 wherein the data interfaceincludes a print task coupled to the file manager task to compile datain the time-specific block file for printing.
 38. A system according toclaim 36 wherein the data storage medium comprises a flash memorystorage device.
 39. A blood processing system comprising a deviceincluding processing hardware to carry out a blood processing procedure,a processing control manager on the device coupled to the processinghardware to monitor status conditions over time during the bloodprocessing procedure, and a data interface on the device coupled to theprocessing control manager including a data storage medium including afirst file space formatted to a fixed maximum size and a second filespace formatted to a fixed maximum size, a data generator task togenerate chronologic data streams based upon status conditions monitoredover time and to generate a time-specific data stream, based upon statusconditions at a point in time, and a file manager task to append thechronologic data streams in chronologic order to the first file spaceand not the second file space and to write the time-specific data streamto the second file space and not the first file space as a time-specificblock file.
 40. A system according to claim 39 wherein the data storagemedium comprises a flash memory storage device.
 41. A method forprocessing data during a blood processing procedure comprising the stepsof monitoring status conditions over time during the blood processingprocedure, generating data based upon monitored status conditions, andwriting the data to a flash memory storage medium.
 42. A methodaccording to claim 41 and further including the step of manipulating thedata written to the flash memory storage medium.
 43. A method accordingto claim 41 and further including the step of retrieving the datawritten to the flash memory storage medium.
 44. A method for processingdata during a blood processing procedure comprising the steps ofmonitoring status conditions over time during the blood processingprocedure, generating a succession of first and second data streamsbased upon monitored status conditions, and writing the first and seconddata streams to a storage medium having allocated first and second blockfile spaces, by appending each first data stream in chronological orderonly to the first block file space and by overwriting each second datastream in succession only to the second block file space, to therebymaintain during the procedure a chronologic block file in the firstblock file space and a time-specific block file in the second block filespace.
 45. A method according to claim 44 and further including the stepof manipulating the data written to at least one of the block filespaces.
 46. A method according to the claim 44 and further including thestep of retrieving the data written to at least one of the block filespaces.
 47. A method according to claim 44 wherein the writing stepincludes writing the first and second data streams to a flash memorystorage medium.